1. Technical Field
The present invention relates generally to controlling execution of actions on a computer system, and more specifically relates to allowing temporal authorization of an executable action on a computer system.
2. Related Art
With the advent of distributed networks, such as the Internet, it has become common practice to allow executable programs to be automatically loaded and executed on networked computer systems. Often such programs are loaded by other programs, such a browser, with little oversight by the user. While such programs may be often be for legitimate purposes, e.g., to update a user's calendar with a new appointment, some actions may be unwanted, e.g., the program may cause unwanted advertisements to be displayed, or worse, execute malicious code such as a virus.
In order to address this problem, many execution platforms, such as LOTUS NOTES™, include an execution control system that allows a user to control what code can be executed on the user's computer based on who signed the code. In particular, an execution control list (ECL) is provided that details which signers/programs are allowed. When code tries to execute something that has not been allowed, an alert dialogue window pops up to notify the user of the problem. Current technology allows the user to address the problem by: (1) not allowing execution; (2) allowing the action to execute this one time; or (3) adding the signer to the ECL so that the signer always has permission to execute the action.
The second option, “allowing the action to execute this one time,” is meant to handle the case in which the user does not want to trust the signer forever for a particular operation, but wants to allow execution this one time. Unfortunately, some operations may occur in a code loop, and thus require permission for each iteration. In these cases, the alert dialogue window may pop up repeatedly, requiring the user to repeatedly select the second option. When these situations occur, it is not unusual for the user to just select option three, thus allowing the program to perform the operation at any time. This has the undesirable effect of reducing security on the user's workstation, as the program may be executed at any time in the future without alerting the user. The only current method for addressing the problem, without manually allowing each iteration to execute, is to manually edit the ECL to remove the added signer from the list of signers allowed to perform the operation, after the actions of the program have been executed. The removal of the permission afterwards is usually forgotten about.
Accordingly, a need exists for a system that addresses the problem of granting execution privileges to an action embedded in a program code loop.